|
|
|
|
|
|
|
activities are in place produces a plan full of guesswork. Such a plan shouldn't be completely relied on as a static representation of what's going to happen in a project and when deliverables will be made. |
|
|
|
|
|
|
|
|
Efforts to prematurely create a static iteration plan often (but not necessarily) result in frustration and low morale. Nonetheless, you can still have a partial iteration plan in place to cover your analysis and design activities. Just keep in mind that it will be extremely dynamic; its volatility will be based on the numerous discoveries you're bound to make that will change its structure. |
|
|
|
|
|
|
|
|
Depending on the object-oriented development process you choose, your iteration plan can be structured in one of two ways: one or more increments per iteration or one or more iterations per increment. If you choose the Objectory Process (the official Unified Modeling Language [UML] process), analysis, design, and construction can be decomposed into iterations, with one or more increments per iteration. |
|
|
|
|
|
|
|
|
New Term: The UML defines an iteration as a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. |
|
|
|
|
|
|
|
|
During each iteration, don't be surprised if you go through analysis, design, construction, testing, and deployment. An iteration can lead to an executable release of your application to one or more groups or market segments of users. Some of these phases, or process components, will require different levels of treatment, depending on monetary and political factors. |
|
|
|
|
|
|
|
|
An iteration plan can be used as the basis for your package structure in Visual Modeler, Rational Rose for Visual Basic, or your pencil-and-paper model. It can also be the basis for your SourceSafe project structure. The iteration plan for the Samsona Bank Teller System example, depicted in Table 10.1, resembles its SourceSafe project structure and can also be the basis for your package structure in Visual Modeler. |
|
|
|
|
| TABLE 10.1. A SAMPLE ITERATION PLAN FOR THE SAMSONA BANK TELLER SYSTEM. THE ASTERISK (*) REPRESENTS NEW DISCOVERIES THAT YOU AND YOUR CLIENT, THE SECOND BANK OF CARROLLTON, AGREE SHOULD BE IN THE REVISED USE-CASE MODEL. | | Iteration | Increment | | 1. Open an Account | 1.0. The customer is a new customer with no previous accounts and has the minimum required balance. | | 2.0. The customer has an existing account that is active. | | 3.0. The customer has an existing account that is inactive. | | |
|
|
|